Can we merge this already? Im waiting for this fix😄 @josephdecock

You can simply update the package version in your host. No need to wait for other libraries to update their dependencies.

@leastprivilege Yes, we can do that. And I did. But there's 10s of thousands of consumers of this package. Wouldn't it be more efficient for your company to address the vulnerable dependency? It has been over a month since this PR was created for a CVE 6.8 vulnerability.

There is precedence for our approach: aspnet/AspNetKatana#522 (comment)

Yes, people do that because we can't wait months for the package maintainer to merge their PR.

The browbeating tone of your message makes it difficult to have an unimpassioned and productive conversation. Please keep it professional.

Back on topic, can you show other examples from Microsoft where they have done such a change? We've taken their approach and guidance on this topic for years. In our experience this is not practical to patch every time a such a dependency changes, especially given the various dependency chains. But if there's new and/or updated guidance, we're more than happy to consider it.

Isn't this why dependabot is a thing? Just click the merge button and tada🪄

Some companies don't use a dependabot and will be exposed to vulnerabilities. As Uncle Ben once said, "with great power comes great responsibility." Lesser known is quote from Aunt May: "Responsible young men update their vulnerable package dependencies." 😉

I appreciate everyone's passion here, but we're in a difficult position here. I'll try to explain below.

Isn't this why dependabot is a thing? Just click the merge button and tada🪄

Unfortunately, it's not that simple. Given the historic issues with diamond dependency problems specifically related to code quality and frequent breaking changes in minor and patch updates to Wilson, we took the approach a long time ago to only reference the exact versions of downstream dependencies that were the same ones as targeted by the base version of .NET and/or ASP.NET we were targeting (e.g. .NET 6 or .NET 8).

This is why, in addition to the guidance we sought from Microsoft about on how to handle these issues, and the fact that hosts using our library have a solution to getting the updated version of the dependency, this hasn't been the highest priority.

We also have not had the time to actually verify that the newer version hasn't broken something else (as they have often done in the past).

So hopefully this provides some context. We do have time on our upcoming schedules to do feature work here, and this will be one of the topics we look into.

Thanks again.